Secure communication systems are well known. Police and public safety personnel, for example, often require secure voice and/or data communications between mobile transmitters and receivers. Such transmitters and receivers include in-car mobile or hand-held portable radios (mobiles) as well as fixed transmitters and receivers, such as a central dispatch station. The communication paths between the mobiles and the fixed end are typically wireless links, such as radio frequency (RF) channels.
Secure communication is made possible by designated transmitters and receivers (“encryption devices”) sharing a traffic encryption key (TEK) that uniquely specifies an encryption algorithm for the communication. Encryption of communications takes place by encrypting all transmissions with the TEK, and having a receiver utilize the TEK to decrypt the received transmissions. Only encryption devices having identical TEKs are capable of intelligibly reproducing the communication. Each individual encryption device may have more than one TEK. For example, it is frequently desirable for supervisory radios to have several different TEKs to communicate with different groups of users each having a different TEK. The TEKs are usually changed periodically, typically weekly or monthly to reduce the likelihood that the keys might be obtained by unauthorized parties.
The process of loading TEKs into the encryption devices, called rekeying, can be accomplished in a variety of ways. Over-The-Air Rekeying (OTAR) is the act of transmitting the TEKs from a centralized Key Management Facility (KMF), over a typical encrypted communication channel to one or more target encryption devices. In some instances, a Key Encryption Key (KEK) is used to encrypt the TEK. Manual rekeying is the act of physically making contact between a key delivery device (e.g., Key Variable Loader, or KVL) and a target encryption device in order to deliver one or more TEKs to the device. A third method, Store and Forward rekeying provides for storing key management messages along with a record of target encryption devices in a key delivery device (e.g., KVL). The key management messages and associated record may be constructed at a centralized KMF and then communicated to the KVL. Then, upon connection of the KVL to the respective targets, the appropriate key management messages are forwarded (communicated) to the appropriate target devices.
In systems employing an APCO Project 25 protocol, Key Management Messages (KMMs) are used to conduct key management operations, including key transfer, between a KMF or KVL and subscriber radio. Message integrity and source authentication of the KMMs is provided by a Message Authentication Code (MAC). The requirements and protocol definitions for using the KMM MAC can be found in TIA 102.AACA-1, section 5.4.
The Project 25 KMM is used to support key management operations for symmetric keys, which include Traffic Encryption Keys (TEKs) and Key Encryption Keys (KEKs). The MAC is also a symmetric key. It is either a dedicated key that is shared between the KMF and subscriber radio, or it is derived from one of the radio's TEKs using a well known algorithm.
There are some conditions where the subscriber radio may not currently have any TEKs or MAC, but needs to conduct key management operations with the KMF in order to obtain a TEK. One scenario is where the radio user plans to give the radio to another user, or to a service shop. A common procedure is to manually erase the current TEKs in the radio before handing it over to the other user or service shop. When the owner gets the radio back, he or she may initiate a rekey request with a KMF/KVL in order to get new TEKs. Since no MAC is present on the radio, the rekey request is transmitted without MAC authentication. As a result, the KMF/KVL can not verify the authenticity of the received rekey request. Without MAC protection, these KMMs are susceptible to tampering or spoofing. Therefore a need exists for a method and apparatus for authenticating a key management message within secure communication systems that reduces the possibility of tampering or spoofing the delivery of encryption keys.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required.